Tech Arsenal 1/Tech Arsenal (Arsenal Computer).ISO/tek-21/qwhite.zip/VIRTUALI.TEC

Text File | 1992-03-09 | 16KB | 300 lines

ID:V1 What is Virtualizing?
Quarterdeck Technical Bulletin #229
by Michael Bolton and Eric Wieling

Q. What is virtualizing?
Q. What does "virtualize text and graphics" mean?
Q. What does "writes directly to screen" mean?
Q. How can I tell if my program writes directly to screen?
Q. I've set "Runs in background" to Y.  Why isn't my program running in
   background?


Q. What is virtualizing?

Programs can handle display in three ways in DESQview parlance.  These are
explained in more detail below, but briefly,

1) the "well-behaved" application uses DOS or your system's BIOS
   services to display its information;

2) the "DESQview-aware" program writes directly to the screen when not
   running under DESQview, but writes to a special area of memory (under
   DESQview's control) so that DESQview may properly manage display of
   multiple windows.

3) the "misbehaved" application writes directly to the screen hardware
   with no consideration for DESQview or any other multitasking
   environment.

Misbehaved applications present a special problem for most multitasking
environments, in that direct screen-writing can "bleed through" into
foreground windows.   However, on a 386 processor, DESQview 386 (which is
simply DESQview and QEMM running on the same computer) can "virtualize"
misbehaved applications; that is, it can fool these applications into
believing that they have exclusive control of the screen.  Thus, such
applications may be run in background or in a small window without interfering
with the display of other applications.

The first thing to know about virtualizing is that, unless you are working on
a 386, 386SX, or i486 machine, AND using DESQview 386, virtualizing means
little to you; anything less than a 386 is not capable of virtualizing the
screen, and only DESQview and QEMM (which together comprise DESQview 386)
provide the memory-mapping services that allow this trick to be performed.
This is another of the many compelling reasons to move to a 386 processor if
you have not already done so.  (For the purposes of this discussion, the
80386SX, the 80386 (also known as the 80386DX), and the i486 are equivalent;
all provide the memory-management features of the 386.)

Now that we've established that we discuss virtualization only when we refer
to a 386, we should look at the way programs display information on the
screen.

From DESQview's perspective, there are two basic types of programs, as far as
display is concerned. The first type of program, the "well-behaved" program in
DESQview parlance, uses DOS or the system's Basic Input/Output Services (BIOS)
to put text on the screen.  The BIOS gets information from the program, and
then puts values into screen memory addresses; these values are then
translated by the display adapter to show up as the characters that you see on
your monitor. "Well-behaved" applications, then, use resources built into the
system to display information.  To run a program in a small window or in
background, DESQview (without QEMM's help, and on any processor) intercepts
DOS and BIOS calls and places the results into a "virtual screen."  This is an
area of memory, or "buffer," the same size as screen memory, which, to the
application, looks and feels exactly like the real screen.  The application
therefore behaves as it would if it had the computer all to itself.  The "well-
behaved" program believes that display work has been done, and continues about
its business without complaints.

Applications which display Hercules, CGA, EGA, or VGA graphics (and this
includes all programs with graphical user interfaces) normally do not use the
BIOS.  Because of the greater complexity involved in displaying graphics, such
programs do not have the option of writing directly to a DESQview memory
buffer, nor are there BIOS services efficient enough to allow such programs to
run at a satisfactory speed.  These applications are therefore, by definition,
NOT well-behaved and are called (predictably) "misbehaved" in DESQview
parlance.  This type of program avoids DOS and the BIOS, and puts text or
graphics on the screen itself by writing values directly into screen memory
addresses.

For text-based applications, writing directly to the screen hardware is
considerably faster than using BIOS calls, so many text applications write
directly to in the interests of speed.  Graphics-oriented BIOS functions are
limited in power and flexibility, and in any case are unacceptably slow, so
graphical applications write directly to the screen.

The DESQview-aware program checks for the presence of DESQview (or Microsoft
Windows, or TopView, an IBM environment with which DESQview is compatible) and
asks for the address of the memory buffer that DESQview will use to store the
program's video information.  The program then writes directly to DESQview's
memory buffer instead of to the video hardware.  This method produces the same
well-governed results as writing through DOS or the BIOS, and is considerably
faster.  This type of application is called "DESQview-aware."

Writing directly to screen memory addresses eliminates the middleman, but the
catch is that direct-to-screen display information cannot be intercepted and
redirected as easily as BIOS calls.  Under anything other than DESQview-386,
such programs will not run smoothly in background or in a small window.  These
programs interact directly with the display hardware, and will write outside
the borders of their DESQview windows; if allowed to run in background or in a
small window, these programs will "leak" or "bleed" into the display windows
of other programs.  The alternative is to suspend the operation of this type
of program while it is in background, which is DESQview's default method of
managing such programs.  This is quite satisfactory for those who want to use
DESQview as a task-switching environment, but not for those who desire
multitasking.

Happily, the 386 processor, QEMM-386, and DESQview, all working together, can
trap the direct screen writes of misbehaved text or graphics programs and
redirect the output of these applications to DESQview's video buffers -- also
called "virtual screens," since as far as the application knows, it is writing
to the screen.  This process is called "virtualizing." The advantage of
virtualizing is that, under DESQview 386, misbehaved text programs and even
programs using Hercules, CGA, EGA, or VGA graphics can run comfortably in
background or in a small window.


Q. What, then, is the difference between "virtualizing text" and "virtualizing
   text AND graphics"?

First, memory usage: a memory buffer for a virtualized text screen only takes
up as much memory (in bytes) as there are places to display a character on the
screen. That works out to 80 (columns) X 25 (rows) X 2 bytes per character
(one byte for the character, and the other for its display attribute), for a
total of 4000 bytes.  If you want to create a virtual screen to catch text-
based data, you won't pay much of a memory penalty.  DESQview uses expanded
memory to virtualize video output, and expanded memory can only be allocated
in 16K chunks (called "pages"). Consequently, it costs 16K, rather than 4000
bytes, of expanded memory to virtualize a text program.  If you want to
virtualize graphics, though, you'll need as much as 272K of available expanded
memory, depending on the graphics mode that the program is using.

Second, there is a difference in the use of the processor's time.  A
virtualized text program is approximately as fast as a nonvirtualized text
program, but virtualizing graphics does take a heavy toll on the processor.
Incidentally, when you are running a virtualized program full-screen and in
foreground, DESQview temporarily suspends virtualization and lets the program
write to the real video memory region; in this circumstance, there is little
extra processor overhead.

Third, it is worth noting that under DESQview 386, even protected mode
programs, also known as DOS-extended programs, can be multitasked, thanks to a
memory-management specification, coauthored by Quarterdeck, called the Virtual
Control Program Interface (VCPI).  It is possible in most circumstances to
virtualize the text output of a program that runs in protected mode.  This is
because most protected mode programs actually switch into real mode to write
text to the screen.  However, programs which write graphics directly to the
screen while in protected mode cannot be virtualized, so DESQview 386 will by
default halt the operation of such programs when they are not using the full
screen.  A newer specification for multitasking, the DOS Protected Mode
Interface, will allow virtualization of protected-mode programs; future
versions of DESQview and QEMM are expected to support this specification.


Q.  How can I tell if my program is writing directly to screen?

To tell if an application is writing directly to the video hardware inside
DESQview, make the following changes in the application's Change a Program
menu:

1) Set "Writes text directly to screen" to N;

2) Set "Virtualize text/graphics" to N;

3) On the Advanced Options screen, blank out the following four fields in the
"Window Position" section: Starting Height, Starting Width, Starting Row, and
Starting Column.  Put blanks in these fields, not zeros.

After these changes have been made, open the program. DESQview will place a
small window border on the screen; if the program comes up and stays within
the small window border, it does not write directly to the screen.  If the
program demolishes the window border and takes the full screen, it is writing
directly to the hardware, and should be virtualized if you wish to run it in
background or in a small window.

Q. Why doesn't my program STAY in background?  It bleeds through on to the
screen when it's background; even though I've set "Runs in background" to Y,
the information from this program keeps showing up in the foreground window.

If it is an application that writes text or graphics directly to screen, one
reason might be that it is not set up to virtualize.  You can amend this by

1) selecting Change a Program from the DESQview Open Window Menu,

2) selecting the program that you want to change, and

3) on page one of the Change a Program Menu, setting "Virtualize text and
graphics" to Y or T.


Q.  When should I virtualize both text and graphics?

If an application does work which you want to continue while the program is in
background or in a small window, and it is a program that does this work while
displaying graphics, set "Virtualize text and graphics" to Y.

Q. When should I virtualize text only?

1) If you have an application which writes text directly to the screen, but
never uses graphics, set Virtualize to T.  Misbehaved text-based applications
are good candidates for this treatment.

2) If you have an application which does write both text and graphics directly
to the screen, but in which you have no need to run the program in background
while graphics are being displayed, set Virtualize to T. A good example of
this type of program is a word processor or a spreadsheet which has a
graphical element to it (a charting or print preview module, for example) that
you never need to run in background or in a small window.  Even if you're not
virtualizing this type of program, you can still place your chart or print
preview in a small window -- the program simply halts, while retaining the
information on screen.  You can still use DESQview's screen management to see
all the parts of the screen you like, but the program's operation is suspended
while it's in the small window. Recalculating and printing, since they usually
take place while the screen is in text mode, can typically continue to run in
background in such programs, since the text mode of the program is being
virtualized.

3) If you have an application which writes text in real mode, but writes
graphics to the screen while in protected mode, again set "Virtualize text and
graphics" to T.  Do this because the program can still be virtualized while
it's in text mode, even though it can't be virtualized while it's displaying
graphics.

Q. I've done all these things and my program STILL won't run in background.
What's wrong?

There are a few possibilities.

You may have set "Virtualize Text and Graphics" on Page 1 of the program's
Change a Program Menu to N.

Solution: set Virtualize Text and Graphics to Y

You may simply be out of memory; when DESQview virtualizes an application's
graphics, it can require up to 272K of free expanded memory.

Solution: make sure that you have enough memory available for virtualizing.
If you have several applications open, close down one or more.  You might also
want to consider upgrading your system by adding more memory.

DESQview 386 cannot virtualize if you have set the Expanded Memory Page Frame
to 0 with QEMM's FRAME=NONE or FRAMELENGTH=0 parameters.

Solution: make sure neither of the above parameters are on the QEMM line in
CONFIG.SYS.

Although DESQview can save and restore most video modes, there are a few that
it can't virtualize.

Solution: try using a lower resolution for the program in question. Text mode,
sometimes known as "CGA mode" for some programs, is a good place to start.
"CGA mode" is something of a misnomer, since you'll actually still get your
normal resolution on an EGA or VGA -- the program just writes to the screen
without being in graphics mode.

To virtualize graphics, you may need more graphics pages.

Solution: on the Advanced Options screen of the Change a Program Menu, set
Graphics Pages to a higher number, such as 2 or 3.

You may not have enough Real Alternate Maps to virtualize a large number of
windows.

Solution: QEMM must provide DESQview with a Real Alternate Map for each
virtualized window.  Since QEMM's default number of Real Alternate Maps is 8,
if you are using more than 8 windows, you'll be unable to virtualize window 9.
Close down an application or two, or specify MAPS=n on the QEMM line in
CONFIG.SYS, where n is a number larger than 8.  Numbers larger than 20 are
unlikely to be helpful.

Programs that start as part of a DESQview startup script, and are put into
background by the script, may not virtualize if they change video modes; when
the video mode changes, they will be suspended.

Solution: for this type of program, make sure that "Runs in Background" is set
to Y, and is not left blank.

A program may be grabbing a hardware interrupt, and may write directly to
screen from inside its hardware interrupt handler.

Solution: in this unusual circumstance, use Manifest in TSR mode, and then
load your program.  Look at Manifest's First Meg / Interrupts screen to
determine the software interrupt which corresponds to the hardware interrupt
the program is grabbing.  When you want to run this program under DESQview,
use the DESQview startup parameter /HW:nn:V, where nn is the number, in
hexadecimal, of the software interrupt above. This will allow DESQview to
virtualize screen writes that occur inside the hardware interrupt handler.

     Finally, it should be noted that DESQview 386 is presently the only
program in existence that will multitask and virtualize misbehaved DOS
applications which use EGA and VGA graphics.  Virtualization is one of the
principal ways by which DESQview can multitask these applications;
understanding the above ideas about virtualization can help you to take the
greatest advantage of DESQview's power.

  ************************************************************************
  *This technical note may be copied and distributed freely as long as it*
  *is distributed in its entirety and it is not distributed for profit.  *
  *          Copyright (C) 1991 by Quarterdeck Office Systems            *
  ************************ E N D   O F   F I L E *************************